An Implementation for Nested Relational Databases

1 Introductim We propose an architecture for implementing nested relational databases. In particular, we discuss the storage structures, their organization and an access language for specifying access plans. The featurw of our implementation are: In this paper we propose an implementation, ANDA’ for the Nested Relational Data Model(NRJ3M). In partitular, we diicuaa the storage structures, their organization, and an access language for specifying access plans. The motivation for our design comes from these observations: A notation for hierarchical tuple identification. One value-driven indexing structure (VALTREE) for the entire database. A main-memory based component (CACHE) for manipulating hierarchical tuple-identifiers. A hashing scheme (RECLISTS) for fast access to data specified by tuple-identifiers. An access language based on the VALTREE, the RECLIST and the CACHE to define access plans for execution of queries. l In the NHDM, select, join and neat are ‘valuedriven’ operations while project and unneat are not. To implement the value-driven operations it is crucial to efficiently determine which attribute and tuplea are associated with a particular ‘value’. In contrast, for ‘structure-oriented’ operations like project and unnest, it is required to efficiently access tuples and their components irrespective of the values contained in them. Data-structures that are well suited for project and unneat are unfortunately not always suitable for the value-driven operations. Hence our proposal for two storage structures where one supports value-driven requests effectively, while the other supports structureoriented operations. Pemusaon to copy without fee all ar put of this granted pvided that the oopies are not made or disrritutcd for direct commercial advantage, the VLDB cop&ht notice md the title of the public&m and its date s~~eer, and notice L given that copying is by permission of the Very Large Data Base Endowment. To copy otbawise. or to republish. mquires a fee ml/or special pcnnizzion fmm the Edowment. l Primary storage on computers has become fairly inexpensive while a disk access is still conaiderably more expensive than a memory access. We exploit this availability of main memory and indicate methods that use the cache to perform queries more efficiently. We chose to implement the NRDM from scratch rather than map it to some other &sting database implemen‘ANDA Acronymafor a Nested Database Architecture. In Hindi, ANDA meen egg, romching you ace likely to find in * neat. Proceedings of the 14th VLDB Conference Los Angeles, California 1988 76 tations for the following reasons: l Tuple components are not necessarily atomic, making the mapping to the relational model difficult [22]. l Query optimizations that exploit the nested relational model cannot be used when the underlying storage structure is relational [3]. l Selections are often made on components deeply nested within tuples [12, 19, 201. l Hierarchical and network models were not developed with high level non-procedural languages in mind [8]. In Section 2 we discuss the architecture of ANDA. In Section 3 we describe a notation for tuple identification and then discuss the storage components of ANDA VALTREE, RECLIST and CACHE. In Section 4 we discuss the operations on these three components and define our access language. In Section 5 we demonstrate how some queries could be implemented in the access language. Finally, in Section 6 we discuss important observations about this implementation and discuss issues that need further investigation. 2 The ANDA Architecture The are: major components of ANDA as shown in Figure 1 VALTREE a tree structure storing all the atomic values present in the tuples and sub-tuples of the database, RECLIST record-list structures which store data as tuples and sub-tuples, CACHE the main memory component of the implementation where tuple-ids are manipulated, DATA-DICTIONARY stores all the important information about structure definitions, ACCESS LANGUAGE INTERPRETER interprets instructions described in the access language, l QUERY LANGUAGE OPTIMIZER this optimizes the query language expression into an access plan, l GRAPHICAL QUERY LANGUAGE this is the one of the user interfaces which maps to the optimizer, . Figure 1: Components of ANDA l OBJECT-ORIENTED INTERFACE This uses the NRDM as the back-end. The typical execution of a query would involve the following steps: